 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 293: Location API 2.0
JCP version in use: 2.6 Java Specification Participation Agreement version in use: 2.0 Description: This specification defines an optional package that enables the developers to use new enhanced location-based features on the JavaTM ME devices. Please direct comments on this JSR to the Spec Lead(s) Team
The following has been updated from the original request: 2012.08.22: The following section has been updated. 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.
TCK: 2012.08.21: North Sixty-One has become the co-Maintenance Lead. Maintenance Lead: Kimmo Löytänä E-Mail Address: jsr293 Telephone Number: - Fax Number: -
Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: Nokia Corporation Name of Contact Person: Kimmo Loytana E-Mail Address: kimmo.loytana Telephone Number: +358 40 527 6423 Fax Number: +358 7180 70530 Specification Lead: Jaana Majakangas E-Mail Address: jaana.majakangas Telephone Number: +358 40 539 7497 Fax Number: +358 7180 70530 Initial Expert Group Membership: Nokia Corporation Supporting this JSR: Ericsson AB Section 2: Request
2.1 Please describe the proposed Specification:This specification defines an optional package that enables the developers to use new enhanced location-based features on the JavaTM ME devices. This API will be designed as an extension to JSR 179 Location API for JavaTM ME, and therefore must remain to be fully backwards compatible with applications using JSR 179. The scope of the API should include the following:
1. Extended features of JSR 179:
o Add the ability to import and export landmarks with JavaTM application. JSR 179 only provides a mechanism to add and modify landmarks on the device, but with this addition, the landmarks and points of interest can be shared for example between two devices. o Clarify and extend the localization support for the landmarks o Specify a set of abstract landmark UI components for adding, editing and selecting landmarks. These components will be independent of the device manufacturer and will allow the user to have similar user experience on landmark handling across different devices and API implementations.
2. Support for geocoding
3. Map support
4. Navigation support Some of these new extensions might be optional and not required from devices implementing only the basic positioning functions. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)JavaTM Platform, Micro Edition The minimum requirement is the JavaTM ME Connected, Limited Device Configuration (CLDC). This optional package should be usable with any JavaTM ME Profile based on the minimum Configuration as well as Profiles based on the Connected Device Configuration (CDC). 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 JSR is targeting to JavaTM Platform, Micro Edition. 2.4 Should this JSR be voted on by both Executive Committees?No. The Executive Committee with responsibility for the JavaTM ME specifications is required to vote on this JSR. 2.5 What need of the Java community will be addressed by the proposed specification?The specification will enable the use of new and enhanced location-based features in JavaTM ME devices. 2.6 Why isn't this need met by existing specifications?JSR 179 provides a compact and generic API that produces information about the device's present physical location to Java applications, but there are new and more advanced use cases and requirements as described in this proposal. Therefore we see a need to have a new successor version for this JSR. However, JSR 179 does provide a good basis for developing this successor standard. This approach not only builds on top of existing solutions but also avoids fragmentation. 2.7 Please give a short description of the underlying technology or technologies:This specification is intended to use the JavaTM ME Connected, Limited Device Configuration (CLDC) v1.1 as a base. This specification enhances the generic JavaTM interface for positioning. As such, this API shall work with any positioning methods, such as GPS or E-OTD, but the core API will not expose features that pertain to one technology only (however it may allow extensions for specific purposes). Map and navigation support is built on top of already existing 3rd party applications providing these features. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.microedition.location 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?Not otherwise, but the device must support some mechanism to determine the physical location of the device. 2.10 Are there any security issues that cannot be addressed by the current security model?The ability to locate a user by determining the position of his or her personal device is expected to introduce certain security concerns and thus every application should not have the permission to use this API. The security framework needed to enforce this access control as well as the policy for deciding about the permissions is out of the scope for this JSR, but necessary for the implementations to solve in some way. For example, the MIDP 2.0 security model provides one way to establish the required security framework for the implementation of this API. 2.11 Are there any internationalization or localization issues?Yes. Some of the geocoding and landmark related features may be locale-specific. The expert group will take these issues into consideration in the API design. 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: Q3/2006 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.We expect to have a geographically distributed expert group, so e-mail is the primary communication method. Teleconferences and face-to-face meetings may be organized 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 Expert Group will provide status updates on the JSR Community Update Page on a monthly basis. These will include at least updates to the anticipated schedule, status of the specification and possible open issues where input is requested from the wider community. 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 and TCK will be delivered as standalone 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).Not applicable 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.These terms only represent the initial commercial terms planned to be used at this time and remain subject to the execution of final legal agreements covering the subject matter hereof to be determined by Nokia at its sole discretion. We will license to all interested parties. Independent implementations will be allowed - TCK and RI will be licensed separately.
Specification:
TCK:
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 179: Location API for J2ME ( http://jcp.org/en/jsr/detail?id=179)
From 3GPP (http://www.3gpp.org), the following specifications may be taken into consideration: Global Positioning System (GPS) Standard Positioning Service Specification ( http://europa.eu.int/comm/dgs/energy_transport/galileo/index_en.htm) Open Mobile Alliance (OMA) Location working group ( http://www.openmobilealliance.org/tech/wg_committees/loc.html) 3.2 Explanation of how these items might be used as a starting point for the work.The 3GPP specifications suggest a set of standards for implementing location services (LCS) on third-generation mobile terminals and networks. GPS and Galileo systems provide positioning services. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
