Printed: Apr 26, 2024
From: http://www.jcp.org/en/jsr/detail?id=170
|
Updates to the Original Java Specification Request (JSR)
The following information has been updated from the original JSR.
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
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
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.
The target platform is primarily server-based applications interacting with content repositories. Desktop platforms may be supported as well.
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.
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.
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.
The Content Repository for Java technology API proposes the package name javax.jcr and would reside entirely within this package tree.
This specification has no software or hardware dependencies outside of other Java Standards.
No
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.
No
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.
The primary mechanism will be email and web-collaboration. Conference calls will be scheduled as needed.
Section 3: Contributions
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
None
Section 4: Additional Information (Optional)
None