 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 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 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 Supporting this JSR: Sun Microsystems, Inc 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: 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: The API may also include support for "pull" parsing (for example, a subset of JSR 173).
2.7.1 SAX2 and Parser API
2.7.2 DOM API Subset
2.7.3 Pull Parser
2.7.4 Higher-level XML Requirements 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
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.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: 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 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 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: Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.None |
