2.1 Please describe the proposed Specification:

This specification will enable the creation of Java ME applications
which combine the ease of authoring and graphical richness of Web UI
technologies (such as XHTML Basic and SVG Tiny) with the power,
flexibility, and breadth of the Java ME platform. The APIs and
conventions defined by this JSR will provide for three styles of Java
and XML UI markup integration:

This specification will provide a binding to the Compound Document
Format (CDF [ http://www.w3.org/2004/CDF]) markups such as WICD (Web
Interaction Compound Document) Mobile 1.0
( http://www.w3.org/TR/WICDMobile/). The specification will define an
API to load, manipulate, interact and render XML markups for user
interfaces. It will follow models of DOM API definitions used by JSR
226 and JSR 280. The Expert Group will collaborate with the W3C CDF
Working Group where appropriate, for example to provide review
comments on the CDF specifications or to request comments on its own
specification.

The specification will also define the conventions that Java archives
should follow to let tools bind Java handlers to events happening in
XML markups.

The platforms specifically addressed for this JSR are CLDC/MIDP and
CDC/PBP, however this JSR may also be supported on other Java ME
platforms. The expert group will also insure that the API is
efficiently implementable on Java SE.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

The platforms specifically addressed for this JSR are CLDC/MIDP and
CDC/PBP, however this JSR may also be supported on other Java ME
platforms. The expert group will also insure that the API is
efficiently implementable on Java SE. While this JSR is submitted as a
Java ME JSR we expect implementations to become available for both
desktop and mobile platforms. We encourage EG participation by desktop
oriented partners.

2.4 Should this JSR be voted on by both Executive Committees?

No, only the Java ME committee.

2.5 What need of the Java community will be addressed by the proposed specification?

This JSR responds to a market need in the mobile device space for the
ability to develop applications by leveraging the skills of multiple
types of developers, including graphics artists who work with
graphical tools, markup and script authors, and Java coders. The goal
is to enable rich UIs coupled with computational tasks beyond the
scope of scripting, all executing on the mobile client. This solution
could also apply to desktop clients as well and the interfaces
developed by this JSR should apply there as well, but the activity and
interest around the CDF work is strong among mobile developers at this
time.

2.6 Why isn't this need met by existing specifications?

JSR 226 and JSR 287 focus on SVG-T and this JSR should coordinate with
the new JSR 287 EG and follow their lead on SVG specific issues and
ensure that functionality defined in this expert group complements the
JSR-287 specification. JSR 280 will define generic uDOM APIs and this
JSR should coordinate with them and generic DOM APIs should be defined
by that EG. This JSR will focus on user agent issues and DOM APIs
specific to CDF. It will also define tooling conventions for
integrating markup and Java code. It may also address other issues
related to combining markup and Java, such as a Java Web Start like
capability for Java ME.

2.7 Please give a short description of the underlying technology or technologies:

This specification will provide a binding to the Compound Document Format
(CDF [ http://www.w3.org/2004/CDF]) markups. The specification will define
an API to load, manipulate, interact and render XML markups for user
interfaces. It will follow models of DOM API definitions used by
JSR 226 and JSR 280.

2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

org.w3c.tbd for DOM APIs
javax.microedition.tbd for other APIs

2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No

2.10 Are there any security issues that cannot be addressed by the current security model?

No

2.11 Are there any internationalization or localization issues?

No

2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No

2.13 Please describe the anticipated schedule for the development of this
specification.

Early Draft Review: Q2/2006
Public Review Draft: Q3/2006
Final specification: Q4/2006 Note that this information has been updated from the original JSR.

2.14 Please describe the anticipated working model for the Expert Group working on developing this
specification.

2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

An observers alias will be created and monthly status updates will be sent to the alias. Members of the expert group who wish to be included on the alias can do so and participate in discussions with the observers.

2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

The RI will be delivered in two bundles to run on Sun's WTK, based on
CLCD 1.1 and MIDP 2.x, and on Sun's CDC toolkit, based on CDC 1.1 and
PBP 1.1. The TCK will cover both CLDC/MIDP and CDC/FP/PBP.

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

N/A

2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

Sun Microsystems, Inc., will make the TCK and RI available for licensing separately:
TCK
Sun will make the TCK available on a stand-alone basis at no charge, without support or any trademark license rights, to qualified not-for- profit entities (including not-for-profit academic institutions) and qualified individuals engaged in efforts to create compatible implementations of the Specification.
All other use is deemed commercial.
Sun will also make the TCK available for commercial use for an initial flat fee and annual maintenance fee.
RI
Sun will make a binary version of the Reference Implementation available at no cost to TCK licensees for the purpose of configuring and supporting the TCK. No right to redistribute the reference implementation is provided.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

3.2 Explanation of how these items might be used as a starting point for the work.

The interfaces defined by this JSR must be compatible and
interoperable with the above specifications. The CDF spec is
still under development and this EG will track that spec and
possibly provide feedback to the CDF WG. We will try to
recruit some members of the CDF WG to join this EG.

Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.