Find JSRs
Submit this Search


Ad Banner
 
 
 
 

JSRs: Java Specification Requests
JSR 280: XML API for JavaTM ME

Updates to the Java Specification Request (JSR)

The following information has been updated from the original JSR:

2007.02.18: FAB: June 2007

Updates to the Java Specification Request (JSR)

The following information has been updated from the original JSR:

2007.02.18: FAB: April 2007

Updates to the Java Specification Request (JSR)

The following information has been updated from the original JSR:

2006.09.15: PR: October 2006
PFD: January 2007
FAB: March 2007
Note that this information has been updated from the original JSR.

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Sun Microsystems, Inc / Nokia Corporation

Name of Contact Person: Ellen Siegel / Pia Niemela

E-Mail Address: ellen.siegel@sun.com / pia.s.niemela@nokia.com

Telephone Number: +1 650 585 9510 / +358 50 480 2576

Fax Number: +1 650 585 9510 / +358 71 807 0560


Specification Lead: Ellen Siegel / Pia Niemela

E-Mail Address: ellen.siegel@sun.com / pia.s.niemela@nokia.com

Telephone Number: +1 650 585 9510 / +358 50 480 2576

Fax Number: +1 650 585 9510 / +358 71 807 0560


Initial Expert Group Membership:

Sun Microsystems, Inc
Nokia

Supporting this JSR:

Sun Microsystems, Inc
Nokia



Section 2: Request

2.1 Please describe the proposed Specification:

This JSR is designed to provide a general purpose XML API for the next generation of mobile devices. So far, Java XML API support for mobile devices has been fragmented: each JSR that requires XML support has specified its own XML subset API. In addition to enhancing the XML support distributed over several JSRs today, a major goal of this JSR is to avoid further fragmentation by proposing an adequate common set of XML APIs for J2ME.

The proposed XML APIs will support:
1.SAX 2 event handler-based parsing
2.Efficient DOM-style document processing

The API may also include support for application-driven "pull" parsing.

The APIs will support both applications that need to work with small XML fragments and applications that must parse or generate complete XML documents. The intention is to support applications as varied as web services, XML messaging, and Web browsers on mobile devices.

The target devices will have substantially more memory and processing power than many current MIDP devices, but will still be limited compared with non-mobile computers.

As far as possible, the proposed XML API is derived from existing API specifications. However, in some cases, either new APIs or APIs from submitted but not yet approved JSRs are suggested.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

This specification is targeted for the Java ME platform.

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 target is the CLDC/MIDP and the next generation CDC-based mobile platforms.

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

No

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

Next generation mobile devices need a Java API capable of supporting XML document processing and web services. XML is by far the most widely used standard for documents and messages interchanged by mobile devices: the XML formats processed by mobile devices include: WML, XHTML, SMIL, SVG, and SyncML, along with special purpose XML markup such as WAP Push service indications. As mobile web services are deployed, SOAP and a potentially unlimited variety of application-specific data formats will also be used. In order for Java applications on advanced mobile devices to participate in this ?XML-connected? universe, they require a complete suite of XML processing APIs.

The requirements are quite varied: web services applications typically need efficient parsing and generation of XML fragments; browsers need to be able to parse relatively complex documents and to support dynamic construction and modification of document contents. The proposed APIs must support all of these use scenarios while adhering to the memory and processing-power limitations of mobile devices.

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

Current, general purpose XML APIs (as specified by JAXP) are targeted at full-sized computing platforms. JAXP includes APIs not required for mobile devices and thus has a relatively large footprint. In addition, lack of adequate XML APIs for mobile devices has led to fragmentary specification of XML API subsets by individual JSRs that require them. For example, JSR 172 specifies a SAX subset API to support Web services, and JSR 226 specifies a DOM subset to support SVG. A key goal of this JSR is to provide an adequate common subset of XML APIs that by its existence helps to avoid further fragmentation of the XML specifications for mobile devices.

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

The XML API will be derived from existing Java specifications. It will include, at least:
A SAX2 API and javax.xml.parsers APIs
A light-weight DOM API

The API may also include support for "pull" parsing (for example, a subset of JSR 173).

2.7.1 SAX2 and Parser API
A basic subset of the SAX2 API and javax.xml.parsers APIs is specified by JSR 172. This JSR will include the JSR 172 API along with some additional enhancements.

2.7.2 DOM API Subset
There are several possible sources for the DOM API specifications. JSR 226 includes a lightweight DOM Level 2 subset that supports minimal manipulation of DOM nodes. This basic functionality should be usable by many XML applications, including, for example, Web services. However, the JSR 226 version is specifically limited to handle only SVG documents, so, at a minimum, the specification would have to be generalized to allow content from any namespace. Also, the DOM model itself is oriented to whole documents, whereas many applications need only manipulate document fragments. This JSR will include a proper subset of the DOM 2 API, and possibly also some extensions to allow document fragment operations.

2.7.3 Pull Parser
"Pull" parsing is a relatively new approach to XML parsing, but preliminary indications are that it may be well suited for limited resource devices due in part to significantly reduced runtime memory requirements. Should this JSR include a pull parsing API, JSR 173 proposes a pull parsing API for Java SE from which a Java ME subset might be drawn.

2.7.4 Higher-level XML Requirements
The XML APIs specified by this JSR cover base, low-level XML parsing functionality for advanced mobile devices. It is anticipated that such devices will also require support for higher-level XML APIs for XML security, Web services, XML data binding and other features. These impose requirements for DOM support, XML exclusive canonization, and other features on the lower-level XML components. The XML APIs in this JSR must provide adequate support for the appropriate higher-level XML APIs.

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

Depending on the DOM API chosen, a new package to support DOM fragments may be required. Otherwise, the proposed APIs are subsets of existing Java packages.

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

None

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

None

2.11 Are there any internationalization or localization issues?

Support for a sufficient set of character encodings is required.

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

This JSR might affect the embedded XML APIs of some existing JSRs, such as the JAXP subset of JSR 172 and the DOM subset of JSR 226. There is no intention of breaking compatibility with these existing APIs.

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

August 2005: EG formed
January 2006: Early Draft Review
2006.09.15:
PR: October 2006
PFD: January 2007
FAB: March 2007 .

Note that this information has been updated from the original JSR.
Note that this information has been updated from the original JSR.
April 2006: Public Review
June 2006: Proposed Final Draft
August 2006: Final Approval Ballot

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

The working interactions will be primarily email communications, with occasional teleconferences/video conferences as appropriate. Face-to-face meetings, which will be tele/videoconferenced, will be arranged as needed and as appropriate.

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.

The transparency plan is:
a) JSR community page is used to provide the community with regular updates of the draft specifications and information about the current topics and issues of the Expert Group.

b) An observer alias is maintained for the JCP members outside of the Expert Group. Periodic milestone draft specifications and status are published to this list. The Expert Group may also use the list to request feedback on key issues facing the group.

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.

Both RI and TCK will be delivered as stand-alone packages.

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 for the XML API for Java ME available for licensing separately:

TCK
Sun will make the XML API for Java ME 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 XML API for Java ME TCK available for commercial use for a flat fee of US$50,000, with an annual maintenance fee of US$20,000.

RI
Sun will make a binary version of the XML API for Java ME 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.

JSR 5: XML Parsing Specification (JAXP): http://jcp.org/jsr/detail?id=5

JSR 63: Java API for XML Processing (JAXP) 1.2: http://jcp.org/jsr/detail?id=63

JSR 206: Java API for XML Processing (JAXP) 1.3: http://jcp.org/jsr/detail?id=206

JSR 173: Streaming API for XML: http://jcp.org/jsr/detail?id=173

kXML: http://kxml.sourceforge.net

JSR 102: JDOM 1.0: http://jcp.org/jsr/detail?id=102

JSR 172: J2ME Web Services Specification: http://jcp.org/jsr/detail?id=172

JSR 226: Scalable 2D Vector Graphics API for J2ME: http://jcp.org/jsr/detail?id=226

JSR 31: XML Data Binding Specification (JAXB 1.0): http://jcp.org/jsr/detail?id=31

JSR 222: Java Architecture for XML Binding (JAXB) 2.0: http://jcp.org/jsr/detail?id=222

JSR 104: XML Trust Service APIs: http://jcp.org/jsr/detail?id=104

JSR 105: XML Digital Signature APIs: http://jcp.org/jsr/detail?id=105

JSR 106: XML Digital Encryption APIs: http://jcp.org/jsr/detail?id=106

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

Unfortunately, XML support in Java has evolved into a somewhat fragmented set of packages. The basic XML parser APIs are the SAX event-based parser, and W3C DOM. In J2SE these have been packaged, together with XSLT support, as JAXP. This was originally specified in JSR-5, was further refined in JSR-63 (JAXP 1.2) and JSR-206 (JAXP 1.3).

At least two other parser APIs have also been submitted to JCP. JSR 173 proposes a streaming (pull) parser. This is aimed at J2SE, but specifies that the API should not preclude support for J2ME and includes a proposed J2ME subset that is intended to have low dynamic memory usage (cursor API). Streaming parser implementations (such as kXML) have been popular for small devices because they require less memory.

JDOM is an alternative open source DOM API designed specifically for Java (the W3C DOM API is an abstract specification with multiple language bindings). This has been proposed to the JCP as JSR 102.

JSR 172 (J2ME Web Services) includes a specification for a limited subset of JAXP 1.2 (JSR 63). It includes only a SAX 2.0 subset and explicitly excludes XSLT and DOM. It also excludes useful components of the SAX 2.0 API, such as the XMLReader interface. While this is adequate for the special purposes of JSR 172, it is inadequate for many other XML processing applications.

JSR 172 specifies in addition to XML SAX parsing APIs also Web services APIs for J2ME. This proposal would split the XML and Web services APIs into two separate specifications. This JSR would be proposed as the XML follow-on for JSR 172. This will require close cooperation with the existing JSR 172 working group.

JSR 226 (J2ME SVG) includes a very lightweight DOM subset, which may be useful as a starting point for DOM support. This JSR should coordinate closely with JSR 226 to specify a consistent DOM subset if possible.

As far as possible, the XML APIs in this JSR should be derived from the existing J2ME JSRs (e.g. JSR 172 and JSR 226) and make a consistent superset of them.

Device support for certain higher-level XML APIs will impose specific requirements on the low-level APIs specified by this JSR. Relevant high-level API specifications may include:
JAXB 1.0 (JSR 31 and JSR 222)
XML Security APIs, including JSR 104, JSR 105, and JSR 106.



Section 4: Additional Information (Optional)

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

None