 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 170: Content Repository for JavaTM technology API
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
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
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 Supporting this JSR: Laird Popkin 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 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: Related Topics:
JTA, Java Transaction API, Version 1.0.1
JMS, Java Message Service, Version 1.0.2
JCA, J2EE Connector Architecture
Workspace Versioning and Configuration Management 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 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
