Find JSRs

Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 170: Content Repository for JavaTM technology API

Stage Access Start Finish
Maintenance Draft Review Download page 22 Mar, 2006 24 Apr, 2006
Final Release Download page 17 Jun, 2005  
Final Approval Ballot View results 17 May, 2005 31 May, 2005
Proposed Final Draft 2 Download page 25 Mar, 2005  
Proposed Final Draft Download page 11 Feb, 2005  
Public Review Ballot View results 13 Jul, 2004 19 Jul, 2004
Public Review Download page 17 May, 2004 19 Jul, 2004
Community Draft Ballot View results 02 Dec, 2003 08 Dec, 2003
Community Review Login page 08 Oct, 2003 08 Dec, 2003
Expert Group Formation   20 Feb, 2002 23 Jul, 2003
JSR Review Ballot View results 05 Feb, 2002 19 Feb, 2002
Status: Maintenance
JCP version in use: 2.6
Java Specification Participation Agreement version in use: 2.0


Description:
Specifies a standard API to access content repositories in JavaTM 2 independently of implementation.

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

Specification Leads
Star Spec Lead David Nuescheler Day Software, Inc.
Expert Group
  Apache Software Foundation Art Technology Group Inc.(ATG) BEA Systems
  Day Software, Inc. Fujitsu Limited Hewlett-Packard
  IBM Mediasurface Ltd. Novell, Inc.
  Oracle SAP SE SAS Institute Inc.
  Sun Microsystems, Inc. Vignette

Updates to the Original Java Specification Request (JSR)

The following information has been updated from the original JSR.

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

Community Draft submitted: oct-2003
Community Review closed: dec-2003
Public Draft submitted: may-2004
Public Review closed: jul-2004
Proposed Final Draft submitted: feb-2005
Final Release: may-2005


Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Day Software

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:

ATG
Day Software
Hewlett-Packard
SAP Portals AG
Software AG

Supporting this JSR:

Laird Popkin
3path
Remy Maucherat
Dirk Verbeeck
ATG
Day Software
Deloitte Consulting
Hewlett-Packard
IBM
Nat Billington
Oyster Partners
SAP Portals
Software AG



Section 2: Request

2.1 Please describe the proposed Specification:

The API should be a standard, implementation independent, way to access content bi-directionally on a granular level within a content repository. 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 are interacting with a content repository 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.

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 What need of the Java community will be addressed by the proposed specification?

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.4 Why isn't this need met by existing specifications?

The Content Industry has defined a number of specifications on a protocol level to exchange content (ICE, WebDAV, etc.). However, there is no specification on an API level that addresses the unique requirements of a Content Repository. As well, there exists no Content Repository centric standard that appears to address issues such as version handling, full-text searching, and event-monitoring in a coherent manner.

Of course, existing standards will be utilized/referenced for various components. For example, JMS or JTA will be used/referenced in this standard. Numerous existing standards/drafts (EJB, EMB, JDBC, JDO, XML-DOM, etc.) with a certain amount of overlap will be taken into account wherever possible. Never the less, none of the standards cover the full range of described issues around Content Repositories.

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

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.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

The Content Repository for Java technology API proposes the package name javax.jcr and would reside entirely within this package tree.

2.7 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.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?

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.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No

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

The final schedule will be determined after the Expert Group's first meeting. The following is a proposed schedule:

jul-2002 Community draft submitted
sep-2002 Community review closed
dec-2002 Public draft submitted
feb-2003 Public review closed
apr-2003 Proposed Final draft submitted
jun-2003 Final release

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

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

The primary mechanism will be email and web-collaboration. Conference calls will be scheduled as needed.





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.

Content Repository for Java technology API Website:
http://jcr.day.com/

Related Topics:

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://www.jcp.org/jsr/detail/147.jsp

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

None



Section 4: Additional Information (Optional)

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

None