Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 283: Content Repository for JavaTM Technology API Version 2.0

Stage Access Start Finish
Final Release Download page 25 Sep, 2009  
Final Approval Ballot View results 01 Sep, 2009 14 Sep, 2009
Proposed Final Draft Download page 31 Mar, 2009  
Public Review Ballot View results 04 Sep, 2007 10 Sep, 2007
Public Review Download page 13 Jul, 2007 10 Sep, 2007
Early Draft Review Download page 31 Aug, 2006 30 Oct, 2006
Expert Group Formation   20 Sep, 2005  
JSR Review Ballot View results 06 Sep, 2005 19 Sep, 2005
Status: Final
JCP version in use: 2.7
Java Specification Participation Agreement version in use: 2.0


Description:
As the version 2.0 of the Content Repository for Java Technology API, the aim is to further expand and refine the specification based on feedback from the community.

Please direct comments on this JSR to the Spec Lead(s)
Team

Specification Leads
Star Spec Lead David Nuescheler Day Software, Inc.
Expert Group
  Alfresco, Inc Alkan, Kilinc Apache Software Foundation
  Art Technology Group Inc.(ATG) Asplund, Marko BEA Systems
  Borland Software Corporation CoreMedia AG Dambekalns, Karsten
  Day Software, Inc. eXo Platform SAS Flowers, Andrew
  Fraunhofer-Gesellschaft Institute FIRST Gershon, Gary M GX Software
  HIPPO IBM Mediasurface Ltd.
  Mobius Management Systems, Inc Myers, Jimmy D. NCsoft Corporation
  Niemeyer, Patrick D. NUXEO Open Text Corporation
  Oracle Pimenta, Marshall Raboch, Walter
  RedHat Reschke, Julian SAP AG
  Saperion AG SAS Institute Inc. Sharma, Sanket
  Sun Microsystems, Inc. Tiwari, Shashank Vignette
  Wadia, Zubin Weisinger, Richard Wilkerson, Peter L.
  Winters, James Wipro Technologies Xythos Software, Inc
  Zitting, Jukka

Updates to the Java Specification Request (JSR)

The following information has been updated from the original JSR:

2008.04.18:
Aug-2006 Early draft submitted
Oct-2006 Early draft review closed
Jul-2007 Public draft submitted
Sep-2007 Public review closed
Jul-2008 Proposed Final draft submitted
Sep-2008 Final release

Updates to the Java Specification Request (JSR)

Updates to the Java Specification Request (JSR)

The following information has been updated from the original JSR:

2007.12.11: Updated Schedule:
---
Aug-2006 Early draft submitted
Oct-2006 Early draft review closed
Jul-2007 Public draft submitted
Sep-2007 Public review closed
Mar-2008 Proposed Final draft submitted
May-2008 Final release

The following information has been updated from the original JSR:

2007.07.02:
Aug-2006 Early draft submitted
Oct-2006 Early draft review closed
Jun-2007 Public draft submitted
Aug-2007 Public review closed
Nov-2007 Proposed Final draft submitted
Jan-2008 Final release .

Updates to the Java Specification Request (JSR)

The following information has been updated from the original JSR:

2007.02.20:
Aug-2006 Early draft submitted
Oct-2006 Early draft review closed
Apr-2007 Public draft submitted
Jun-2007 Public review closed
Sep-2007 Proposed Final draft submitted
Nov-2007 Final release

Updates to the Java Specification Request (JSR)

The following information has been updated from the original JSR:

2006.03.20: May-2006 Early draft submitted
Jul-2006 Early draft review closed
Nov-2006 Public draft submitted
Jan-2006 Public review closed
Mar-2007 Proposed Final draft submitted
May-2007 Final release

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Day Software AG

Name of Contact Person: David Nuescheler

E-Mail Address: david.nuescheler@day.com

Telephone Number: +41 61 226 98 98

Fax Number: +41 61 226 98 97


Specification Lead: David Nuescheler

E-Mail Address: david.nuescheler@day.com

Telephone Number: +41 61 226 98 98

Fax Number: +41 61 226 98 97


Initial Expert Group Membership:

Apache Software Foundation
Art Technology Group Inc.(ATG)
BEA Systems
Day Software, Inc.
Documentum, Inc.
Filenet Corporation
Fujitsu Limited
Hewlett-Packard
Hummingbird Ltd.
IBM
Interwoven
Macromedia, Inc.
Mediasurface Ltd.
Novell, Inc.
Opentext
Oracle
SAP AG
SAS Institute Inc.
Software AG
Stellent, Inc.
Sun Microsystems, Inc.
Venetica Corporation
Vignette

Supporting this JSR:

Apache Software Foundation
Art Technology Group Inc.(ATG)
BEA Systems
Day Software, Inc.
Documentum, Inc.
Filenet Corporation
Fujitsu Limited
Hewlett-Packard
Hummingbird Ltd.
IBM
Interwoven
Macromedia, Inc.
Mediasurface Ltd.
Myers, James D.
Nix, Markus
Novell, Inc.
Opentext
Oracle
RedDot Solutions AG
SAP AG
SAS Institute Inc.
Software AG
Stellent, Inc.
Sun Microsystems, Inc.
Venetica Corporation
Vignette
Xythos
Zitting, Jukka



Section 2: Request

2.1 Please describe the proposed Specification:

Since this JSR represents an enhancement of JSR-170, the same general goals apply to this JSR as to JSR-170 (from the JSR-170 proposal):

The aim is to produce a content repository API that provides an implementation independent way to access content bi-directionally on a granular level. A content repository is a high-level information management system that is a superset of traditional data repositories. A content repository implements ?content services? such as: author based versioning, full textual searching, fine grained access control, content categorization and content event monitoring. It is these ?content services? that differentiate a content repository from a data repository. Many of today?s (web) applications interact with content repositories in various ways. This API proposes that content repositories have a dedicated, standard way of interaction with applications that deal with content. This API will focus on transactional read/write access, binary content (stream operations), textual content, full-text searching, filtering, observation, versioning, handling of hard and soft structured content.

In particular, the following functional areas will be reviewed by the expert group for possible inclusion in version 2.0:

    - Extensions in the area of management of a content repository such as access control management, workspace and nodetype management, retention aspects of content or repository construction patterns.
    - Improvement of content repository interoperability through the addition of new standardized node types, including node types for meta information and internationalization.
    - Extensions to content modelling capabilities.
    - Federation, cross-repository and cross-workspace functionality.
    - Active development of existing query-languages, versioning and observation.
    - Remoting and client/server protocol mappings.
    - Possibly other enhancements.

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

The target platform is primarily server-based applications interacting with content repositories. Desktop platforms may be supported as well.

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.

This JSR is submitted to the J2SE/J2EE EC.

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

No. It should be voted on only be the J2SE/J2EE committee.

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

Since this JSR is the successor to JSR?170 the issues addressed are the same (from the JSR-170 submission):

Today, (web) applications have to adapt to every vendor's proprietary API to interact with content repositories. This has the negative effect of locking a large percentage of information assets in vendor specific formats, limiting access to information, impacting system evolution/migration, and availability of third party content management tools. This API will examine solutions to these and other issues deemed important by the expert group.

There is no easy way to integrate content-producer-applications (CMS) and content-consumer-applications (CRM, Personalization, Portal, etc.) independently of the actual underlying content repository. The expert group will examine solutions to this problem also.

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

As the successor to JSR?170 the issues that the expert group is going to review are extensions that that were not considered in JSR-170 for timing and specification-size reasons.

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

Since this JSR is the successor to JSR?170 the underlying technology is the same (from the JSR-170 submission):

The following functional areas will be reviewed by the expert group for possible inclusion:

Granular Read/Write Access - This is the bi-directional interaction of content elements. Issues with access on a property level and not just on a "document" level should be examined. A content transaction is any operation or service invoked as part of a system interaction with a content repository.

Versioning - Transparent version handling across the entire content repository, would provide the ability to create versions of any content within the repository and select versions for any content access or modification. Hard- and Soft-structured Content - An Object Model that defines how hard and soft-structured content could be addressed will be examined.

Event Monitoring (Observation)- Possible use of JMS based notification framework allowing for subscription on content modification will be examined.

Full-text Search and filtering - The entire (non-binary) content of the repository could be indexed by a full-text search engine that enables exact and sub-string searching of content. The API will examine ways to standardize how content is queried, whether full-text or parametric. Of course, existing standard query languages will be respected.

Access Control - Unified, extensible, access control mechanisms will be examined. Standards such as JAAS or ACL standards shall be taken into account.

Object Classes - Profiles or Document Types could be defined and inherited to allow constraints and to give the application programmer the ability to operate on content object types.

Namespaces & Standard Properties - Defining default standard properties that will maintain namespace uniqueness and hierarchy will be examined.

Locking and Concurrency - Standardized access to locking and concurrency features of a repository will be examined.

Linking - A standard mechanism to soft/hard link items and properties in a repository along with providing a mechanism to create relationships in the repository will be examined.

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

The same package name will be used as in JSR-170: javax.jcr and subpackages.

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

This specification has no software or hardware dependencies outside of other Java Standards.

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

No

2.11 Are there any internationalization or localization issues?

Even though the Content Repository implementation itself may have to deal with localization and internationalization issues there are none that have to be taken into account for the standard.

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.

Jan-2006 Early draft submitted
Mar-2006 Early draft review closed
Jul-2006 Public draft submitted
Sep-2006 Public review closed
Nov-2006 Proposed Final draft submitted
Jan-2007 Final release

Note that this information has been updated from the original JSR.

Note that this information has been updated from the original JSR.

Note that this information has been updated from the original JSR.

Note that this information has been updated from the original JSR.

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 specification will be authored in a collaborative development style, known from open source communities. The main means of communication are based on a mailing list, a weekly conference call and face-to-face meetings as required

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.

Like it?s predecessor JSR-170 the specification, the API code, RI and TCK will be under an Apache-based licence, thus providing the maximum in transparency and involving the community and the public to the maximum extent.

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 built upon the current RI and TCK which is hosted by the Apache Foundation under the name of ?Jackrabbit?. The RI and TCK are stand-alone.

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.

The Specification, the RI and the TCK will be available under an Apache-based license, just as they are with JSR-170.





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.

Version 1.0 of the Content Repository For Java Technology API (JSR-170).
http://www.jcp.org/en/jsr/detail?id=170 and
http://jcr.day.com/

Related Topics:

Apache Jackrabbit Project (currently in incubation)
http://incubator.apache.org/jackrabbit

JTA, Java Transaction API, Version 1.0.1
http://java.sun.com/products/jta

JMS, Java Message Service, Version 1.0.2
http://java.sun.com/products/jms

JCA, J2EE Connector Architecture
http://java.sun.com/j2ee/connector/

Workspace Versioning and Configuration Management
http://jcp.org/jsr/detail/147.jsp

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

Version 1.0 of the specification (JSR-170) will be the basis of version 2.0 (this JSR).



Section 4: Additional Information (Optional)

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

None