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

Specification Leads
�	Geoffrey�Clemm	IBM
Expert Group
�	Baedke, Manfred	Broadvision Inc.	Day Software, Inc.
�	IBM	Oracle	Serena Software Inc.
�	Software AG	Sun Microsystems, Inc.

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Rational Software

Name of Contact Person: Geoffrey Clemm

E-Mail Address: [email protected]

Telephone Number: +1 781 676 2684

Fax Number: +1 781 676 2400

Specification Lead: Geoffrey Clemm

E-Mail Address: [email protected]

Telephone Number: +1 781 676 2684

Fax Number: +1 781 676 2400

Initial Expert Group Membership:

Rational Software

Section 2: Request

2.1 Please describe the proposed Specification:

Collaborative authoring tools, including tools targeted for software development, document management, and web content management, need access to a variety of services for versioning and configuration management of the files and web resources being created and modified. The DeltaV protocol (which is an extension to the WebDAV protocol, which itself is an extension of the HTTP/1.1 protocol) provides a standard protocol for versioning and configuration management of web resources. The DeltaV protocol is the result of a three-year collaborative effort by a wide range of participants from the open source community, academics, and industry (e.g. IBM, Oracle, Merant, Microsoft, Rational). But this protocol has the following problems when used by a client:
- The client often needs to maintain copies of the web resources in the client file system (e.g. for disconnected use and performance improvement). Unless clients agree on how that local file system state is maintained, it is impossible for multiple clients to maintain correct local file system state.
- DeltaV (since it is a client-server protocol) provides no standard mechanism for requesting information from the user to complete a requested operation.
- There is a large amount of boilerplate coding required to generate and receive HTTP messages. It is far simpler and less error prone for a client application to simply invoke Java routines.
- There are two significantly different variants of the DeltaV protocol: the client-workspace package and the server-workspace package.
From a client's perspective, these two packages provide the same functionality, and only differ by whether or not persistent state is maintained on the client.

This specification will address these problems by defining a client side library that will expose the full DeltaV functionality and will use the DeltaV protocol to communicate with a server, but will:
- automatically provide client-side file maintenance required by any DeltaV operation
- define GUI callbacks for requesting from the user any information required to complete an operation
- generate the DeltaV messages and parse the DeltaV responses
- hide the distinction between a client workspace and a server workspace in the client side library implementation, so that a user of the
library is presented with a single uniform workspace interface.

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

J2EE/J2SE

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

A common API to versioning and configuration management services will significantly increase the ability for software development, document management, and web content management tools to interoperate with a variety of versioning and configuration management service providers.

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

No existing specification deals with versioning or configuration management of files and web resources.

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

All communication between the client library and the server that provides the versioning and configuration management services will be done over the DeltaV protocol, which is an application of the HTTP/1.1 protocol.

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

javax.wvcm

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

None

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

None

2.9 Are there any internationalization or localization issues?

Various routine arguments will take strings that will need to be internationalized, such as version descriptions.

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

None

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

Community draft submitted by 11/1/01
Community review closed 12/1/01
Public draft submitted by 2/1/02
Public review closed 3/1/02
Proposed Final draft submitted 4/1/02
Final release 5/1/02.

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

The primary mechanism will be email. In addition, a weekly conference call will be scheduled, to be used when needed. If higher-bandwidth communication is required, a 2 day mid-week meeting (Tue/Wed or Wed/Thu) will be held at most once a month, where the location will rotate among the contributing experts.

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.

http://www.ietf.org/internet-drafts/draft-ietf-deltav-versioning-16.txt (DeltaV)
http://www.ietf.org/rfc/rfc2518.txt (WebDAV)
http://www.ietf.org/rfc/rfc2616.txt (HTTP/1.1)
jsr-5 (XML Parsing Specification)

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

The Workspace Versioning and Configuration Management library will use the DeltaV/WebDAV/HTTP protocol to communicate with the server. The DeltaV protocol is defined in an internet draft (soon to receive an rfc number), the WebDAV protocol is defined in rfc2518, and the HTTP protocol is defined in rfc2616. The XML Parsing Specification will be considered as the mechanism for manipulating the XML content of the DeltaV protocol.

Section 4: Additional Information (Optional)

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

None