  
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 
 |
|
 JSRs: Java Specification Requests
JSR 283: Content Repository for JavaTM Technology API Version 2.0
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
Updates to the Java Specification Request (JSR) The following information has been updated from the original JSR:
2008.04.18: 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: The following information has been updated from the original JSR:
2007.07.02: Updates to the Java Specification Request (JSR) The following information has been updated from the original JSR:
2007.02.20: 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 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 Telephone Number: +41 61 226 98 98 Fax Number: +41 61 226 98 97 Specification Lead: David Nuescheler E-Mail Address: david.nuescheler Telephone Number: +41 61 226 98 98 Fax Number: +41 61 226 98 97 Initial Expert Group Membership: Apache Software Foundation Supporting this JSR: Apache Software Foundation 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:
- 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 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). Related Topics:
Apache Jackrabbit Project (currently in incubation)
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.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 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
