• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs



Register for Site

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy


• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

Updates to the Original JSR

This following information has been updated from the original specification.

Supporting this JSR:

Argogroup
Covigo
Volantis
Web Commerce Group

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

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

Note that this section was updated when Sun became the sole Spec Lead of JSR 188.

The expert group members will determine the nature of the working model. It is anticipated that a mixture of email discussions, regular teleconference meetings, and occasional face to face meetings will work well.

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Sun Microsystems, Inc.

Name of Contact Person: Luu Tran

E-Mail Address: luu.tran@sun.com

Telephone Number: +1 408 276 4618

Fax Number: +1 408 276 4942

Specification Lead: Luu Tran/Mark Butler

E-Mail Address: luu.tran@sun.com/ mark-h_butler@hp.com

Telephone Number: +1 408 276 4618/+44 117 312 8832

Fax Number: +1 408 276 4942/+44 117 312 8925

Initial Expert Group Membership:

Art Technology Group Inc.(ATG)
Fujitsu Limited
Hewlett-Packard
IBM
Intel
Oracle
Panasonic
Sun Microsystems, Inc.

Supporting this JSR:

Argogroup
Covigo
Volantis

Section 2: Request

2.1 Please describe the proposed Specification:

Delivery context is a set of attributes that characterizes the capabilities of the access mechanism and the preferences of the user [1]. An access mechanism is a combination of hardware (including one or more devices and network connections) and software (including one or more user agents) that allows a user to perceive and interact with the Web using one or more interaction modalities (sight, sound, keyboard, voice etc.) [1]. Web servers and applications that adapt content for multiple access mechanisms must be sensitive to delivery context.

Composite Capability/Preference Profiles (CC/PP) [2] has been established as the industry standard for describing delivery context. User Agent Profile (UAProf) [3] is based on CC/PP and has been embraced by the WAP community including gateway vendors and handset manufacturers who have embedded UAProf into their products.

This specification will define a set of APIs to process delivery context information in CC/PP.

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

A Java extension for the J2EE^TM platform.

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

This specification will provide the Java community with a standard set of APIs for processing delivery context information that is compatible with the vast majority of web access mechanisms that participate in delivery context negotiation. This will allow Java developers to write device independent code that can deliver content to a multitude of web access mechanisms while reducing development costs, and will help to avoid a proliferation of proprietary and potentially incompatible implementations.

Web servers and applications will be able to use this API to optimally adapt content for individual access mechanisms. J2EE^TM Client Provisioning servers will be able to use this API to help determine the appropriate client application to provision. Portal servers will be able to use this API to adapt content and pass on delivery context information to portlets that would adapt their behavior accordingly.

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

There are no existing Java specifications that deal with processing delivery context information in CC/PP.

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

This specification will depend on CC/PP [2] which uses RDF [4] (a framework for processing metadata) which uses XML [5]. This specification will not define a generalized API for RDF.

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

To be determined by the expert group.

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

No

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

No

2.9 Are there any internationalization or localization issues?

Yes, locale and charset are part of the delivery context. The expert group will work through the relationship between this specification and existing methods of internationalization and localization.

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

No. However, JSR 124 (J2EE^TM Client Provisioning Specification) and JSR 168 (Portlet Specification) are currently in progress. Both of these JSRs deal in part with processing of delivery context and should be aligned with this specification.

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

To be determined by the expert group.

NOTE that this section has been updated from the original request.

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

The expert group members will determine the nature of the working model. It is anticipated that a mixture of email discussions, regular teleconference meetings, and occasional face to face meetings will work well.

It is expected that both specification leaders will fully share responsibilities associated with group leadership, including group communications, decision making, and agreeing to the business terms for the Reference Implementation (RI) and Technical Compatibility Kit (TCK). Exact details will be agreed on early in the life of this specification and communicated to expert group members.

The specification and associated Javadocs will be managed by Sun Microsystems, Inc.

The RI and TCK will be managed by Hewlett-Packard.

Note that this section has been updated from this original submission.

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.

[1] W3C: Device Independence Principals http://www.w3.org/TR/2001/WD-di-princ-20010918/

[2] W3C: Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies http://www.w3.org/TR/2001/WD-CCPP-struct-vocab-20010315/

[3] WAP Forum: User Agent Profile (UAProf) http://www1.wapforum.org/tech/documents/WAP-248-UAProf-20011020-a.pdf

[4] W3C: Resource Description Framework (RDF) Model and Syntax Specification http://www.w3.org/TR/REC-rdf-syntax/

[5] W3C: Extensible Markup Language (XML) 1.0 http://www.w3.org/TR/REC-xml

[6] Apache: DELI/Cocoon http://xml.apache.org/cocoon/developing/deli.html

[7] University of Wales: Device Independent Content Engine (DICE) http://dice.ccpp.info/

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

The expert group will study the specifications to ensure compliance with existing standards and consider existing open source implementations as a basis for the reference implementation for this specification.