The Java Community Process(SM) Program - JSRs: Java Specification Requests

About JCP
Get Involved
- Overview
- Becoming a JCP Member
Community Resources
Community News
FAQ
Contact Us

JSR #327
Dynamic Contents Delivery Service API for Java^TM ME
Public Review Ballot
Ballot duration: 2009-11-17 to: 2009-11-23

These are the final results of the Public Review Ballot for JSR #327. The Executive Committee for ME has approved this ballot.

Votes

AT&T

Aplix Corporation

IBM

Nokia Corporation

Orange France SA

Research In Motion, LTD (RIM)

SK Telecom Co., Ltd.

Samsung Electronics Corporation

Sheedy, Sean

Siemens AG

Sony Ericsson Mobile Communications AB

Sun Microsystems, Inc.

T-Mobile

Time Warner Cable Inc.

Vodafone Group Services Limited

Icon Legend
Yes
No
Abstain
Not voted

View Vote Log

On 2009-11-17 Siemens AG voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-11-17 Sheedy, Sean voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-11-17 Orange France SA voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-11-23 Sony Ericsson Mobile Communications AB voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-11-17 SK Telecom Co., Ltd. voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-11-22 AT&T voted Yes with the following comment:
This JSR is not very readable. An editorial review is needed.
------------------------------------------------------------------------------
On 2009-11-18 Aplix Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-11-23 Nokia Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-11-23 Sun Microsystems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-11-23 Samsung Electronics Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-11-23 Vodafone Group Services Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-11-18 IBM voted No with the following comment:
General:
This JSR is terse and not very readable. At the least, it needs an editorial pass to improve the grammar (make it readable and less terse).

It's only a piece part of DCD - so where's the real spec for the DCD client? Surely it's not to be buried in the "application" as it shown in the diagrams etc. The hard parts of DCD are the scene handling, including partial updates etc, local application processing (script), and presentation. The interface to the delivery framework is not the meat of DCD - yet this seems all that is dealt with.

It would be better to be specific re normative language. Words like "can" appear in this JSR which do not fit within the MUST, SHOULD, etc. normative language cited towards the beginning. For example, "Application can receive notification synchronously or asynchronously." Does this mean the framework and JSR327 implementation and most importantly the application MUST support this to ensure interoperability?

Specific:

5.1.2 - It says "Since the application can not use concurrently both raw and chunked communication within a connection, the application designer should determine which is suitable for their services ." DCD applications designers should not need to know whether the end device is a Java DCD client or some other non Java implementation. OMA's spec is written that way - completely agnostic as to client environment/transport used. Therefore, suggesting the application designer needs to determine this seems completely at odds with the OMA spec this is a Java realization of.

Fig 7 - The states are puzzling. A "Create" should create a state of "active", which from there can be suspended and thence resumed. As written, the spec implies the create leads to a resume state. Resume and suspend are not states. They are transitions.

I'm not convinced the level of detail in this JSR would lead to multiple interoperable implementations - a pre-req of interoperability. 
------------------------------------------------------------------------------