JSRs: Java Specification Requests
JSR 290: JavaTM Language & XML User Interface Markup Integration
The following information has been updated from the original JSR:
2007.02.19: EDR: Q1 2007.
Section 1. Identification
Submitting Member: Sun Microsystems, Inc
Name of Contact Person: Bartley Calder
E-Mail Address: bartley.calder
Telephone Number: +1 408 276 6733
Fax Number: +1 408 276 7201
Specification Lead: Vincent Hardy
E-Mail Address: vincent.hardy
Telephone Number: +33 6 83 17 62 83
Fax Number: +1 408 276 7209
Initial Expert Group Membership:
Sun Microsystems, Inc
Supporting this JSR:
Sun Microsystems, Inc
Section 2: Request
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:
1) cross-referencing between markup and Java ME code
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.
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)
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?
2.10 Are there any security issues that cannot be addressed by the current security model?
2.11 Are there any internationalization or localization issues?
2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?
2.13 Please describe the anticipated schedule for the development of this specification.
Early Draft Review: Q2/2006
2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.
A kickoff face-to-face meeting, weekly concalls, and additional face-to-face meetings as needed.
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).
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:
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.
Compound Document Formats: http://www.w3.org/2004/CDF
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.