These are the final results of the Public Review Ballot for JSR #262. The Executive Committee for SE/EE has approved this ballot.
JSR262
StagePublic Review Ballot
Ballot durationMay 13, 2008 to May 19, 2008
Votes

SE/EE

Apache Software Foundation
Eclipse Foundation, Inc
Fujitsu Limited
Google Inc.
Hewlett-Packard
IBM
Intel Corp.
Lea, Doug
Nortel
Oracle
Red Hat
SAP SE
SAS Institute Inc.
Suleiman, Hani
Sun Microsystems, Inc.
Vote Log

SE/EE

On 2008-05-14 Sun Microsystems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2008-05-19 Oracle voted No with the following comment:
Oracle is reluctantly casting a no vote for the PRD of JSR 262 because of normative references to proprietary specifications. We have a general concern about the use of proprietary specifications in the final release of a JSR. As it applies to this JSR we have the following concern. 

JSR 262 depends on four proprietary specifications: 
a) WS-Transfer 
b) WS-Eventing 
c) WS-Enumeration 
d) WS-Addressing 

At this time, the first three specifications have not been submitted to any standards organization for formal adoption. We are aware that the authors of the proprietary specifications are considering contributing them to a formal open standards organization, but at this time that has not taken place. WS-Addressing is a formally approved W3C Recommendation. But JSR 262's normative references to the proprietary specifications, WS-Transfer, WS-Eventing and WS-Enumeration, in turn normatively reference an earlier proprietary version of WS-Addressing and not the approved W3C Recommendation. Furthermore, there is a conflict between JAX-WS using the W3C Recommendation of WS-Addressing and 262 using an older version -- does not bode well for composability.

A JSR which goes final with a dependency on proprietary specifications means that for the purpose of assuring backward compatibility this dependency will be preserved even if the proprietary specifications are standardized in the future and JSR 262 is updated to reflect that. This is an even larger concern given the fact that 262 is meant to be part of Java 7. 

We have previously communicated these concerns to the spec lead through the EG. Appendix B.1 was added to the PRD as a response to our concern. Unfortunately, B.1 does not address our concern about normative references to proprietary specifications but rather talks only about how the 262 final specification will be updated if and when the referenced proprietary specifications become standards in an open ended fashion. Specifically, it says: 

    "If at the time this specification (JSR 262)
     is finalized those [standardization of 
     referenced proprietary specifications]
     efforts are not complete, we will need to 
     define how this specification will 
     later be updated when they are." 

We understand the necessity and support the creation of Java standards in parallel with standardization efforts of the dependent specifications. But we believe that a JSR cannot be finalized unless and until the dependent specifications reach a suitable stable state and are on a path to approval by a recognized open standards organization. We view the creation of a Java standard that depends on a proprietary specification as an indirect way of "rubber stamping" the referenced proprietary specification as a standard, without the proprietary specification having to go through the usual standardization process. 

We would be happy to change our vote to yes, if the PRD Appendix B.1 is changed to include a commitment to not rely on any proprietary specification in the final release of 262.

------------------------------------------------------------------------------
On 2008-05-15 IBM voted No with the following comment:
We recognize that the specification is not in a final state and that it raises some issues that are still to be addressed by the EG and the community, however, as this is targetted for use with the SE/EE platform, we have serious reservations with the current public review draft that must be resolved now.  

The WS-Connector endpoint must be described by a standard WSDL document.
It must be possible to implement both client and service using the above standard WSDL document and the JAX-WS and JAXB tools and runtime that come with the current JDK.
It must be compliant and based on complete WS-* standards for interoperability.
It must be WS-I profile compliant.

All of the above are basic requisites for being part of the SE/EE platform and this JSR should not be an exception.  We have not seen that the above requirements have been met.  For example, the current public review draft contains a statements that implies the JSR will go to a final stage regardless of the state of standards it is dependent on.  This breaks a long established principle that JSRs should not depend on incomplete specifications or standards.  WS-Management itself depends on specifications which have not gone through a standards approval process.  In addition, we do not understand how the current web services JSRs and tools will support interaction with the WS-Connector service.  Until these fundamental issues are addressed, the specification is not ready to exit Public Review.

------------------------------------------------------------------------------
On 2008-05-19 Intel Corp. voted No with the following comment:
With this being brought to the ECs attention so close to the end of the vote (and when some of the EC are traveling to a meeting), there isn't enough time to track this down.  We are particularly concerned about a normative reference that conflicts with what is now a W3C spec. If the Spec Lead agrees to republish a Public Draft immediately after the vote concludes that removes the statement about publishing a final spec even if normative references aren't specs and also includes a statement that the issue of references and timing for the final spec will be discussed with the EC - under those conditions the PMO can change our vote to yes.  To be clear about this -- the approved Public Draft cannot say that they'll publish the final spec regardless of the state of the normative references.

It doesn't help with this instance, but perhaps JCP also needs a concept like Member submissions in W3C (which in W3C can also be issued by members in a Working Groups).  When a technology has not matured to the point where it can be standardized a "note" or "submission" can help build consensus in trial implementations.  
------------------------------------------------------------------------------
On 2008-05-19 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2008-05-19 SAS Institute Inc. voted Yes with the following comment:
The concerns of the other EC members should be addressed prior to final approval ballot.
------------------------------------------------------------------------------
On 2008-05-19 Google Inc. voted Yes with the following comment:
Like SAS, we trust that the concerns of other EC members will be addressed prior to the final approval ballot, and we believe it advisable to let the JSR proceed with this understanding.

------------------------------------------------------------------------------
On 2008-05-19 SAP SE voted Yes with the following comment:
The serious concerns raised by Oracle and IBM relate to the Web Services Management stack which is being utilized in this JSR, but which is standardized elsewhere (W3C and DMTF). Therefore, we do believe that these concerns should be dealt with in the respective standards organizations as opposed to the JCP. 

At the same time, our expectation is that the Expert Group will not proceed to the final stage of this JSR unless those issues are properly resolved. Given the past experience with W3C member submissions (e.g. WSDL 1.1), the resulting interoperability issues may be severe and cannot be properly addressed unless an open standards process is put in place for WS-Transfer, WS-Enumeration and WS-Eventing in W3C. 

Unless the Web Service Management stack is available in an interoperable way, this JSR will have very limited business value and should not be included in a future Java SE or EE release.

------------------------------------------------------------------------------
On 2008-05-19 Lea, Doug voted Abstain with the following comment:
This spec seems fine technically. The EC was not given enough time to investigate the WC-* dependency concerns, and whether the failure of the W3C to come to timely agreement on their standards poses any risk for JCP standards that are forced to rely on preliminary forms.
------------------------------------------------------------------------------
On 2008-05-19 Fujitsu Limited voted No with the following comment:
As other ECs stated, this JSR contains a problem that it depends on some non-standard specifications. We cannot vote for this JSR unless changed appropriately.
------------------------------------------------------------------------------
On 2008-05-19 Suleiman, Hani voted Yes with the following comment:
My yes vote is based on similar assumptions to Google and SAS; namely that the IBM and Oracle concerns would be addressed satisfactorily before final approval.
------------------------------------------------------------------------------
On 2008-05-19 Eclipse Foundation, Inc voted No with the following comment:
Eclipse votes no for, with the same reservations on IP issues raised by others here.
------------------------------------------------------------------------------