JSR 170: Content Repository for Java is now available for Public Review.
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.JSR 170: Content Repository for Java home pageDownload JSR 170 Public Review
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.
(Close of Public Review: 19 July 2004)In related JCP news:
JSR 200: Network Transfer Format for Java Archives has a Proposed Final Draft Specification available.
The Expert Group of JSR-000215 Java Community Process version 2.6 has published the Final Release
I'm off to burn my eyes out now that they are completely useless from reading that spec. Really, let's go create an API that completely ignores anything and everything already in the J2SE API or the J2EE API. Brilliant plan.
More later when I recover.
...and with the TCK and RI under an Apache license... Thanks Day and nice job!
..to judge that this is a completely useless specification. An API for a content repository requires some provider implementing it - aka document management system. There are various of these around, but one thing they have in common is that they are based on very different abstractions, tools, content update procedures including workflows, different security abstractions and so on and so on. The general idea of even trying to create a read/write api to it is plainly nuts. Just look at SPIs for content that were around for a long time, like the one that comes with BEA's WebLogic Portal product. There you have about 7 or so years of experience of how to interface with a generic CMS, yet it does a lot less than what this spec is trying to achieve, for a very good reason.
Excepted that most of the lead document and web management systems are in the expert group: Documentum, Inc.,Interwoven, Stellent, Inc., Vignette, Filenet Corporation, Hummingbird Ltd., Mediasurface Ltd., Day Software, Inc.,...
And if you read the spec, every CMS may quite easily implement and integrate some JSR170 compliant API (especially the level 1) on top of their respective architecture...
The CMS industry is perhaps the less-standardized computing area... so perhaps not so bad that a spec was jointly agreed by most of the key vendors... Of course this is a version 1.0 but it will be as useful as the JSR168 regarding portlets standardisation...
I've read through much of the specification and believe it to be becoming well fleshed out. I appreciate yours and other responsible parties efforts on this JSR. I've also followed some e-mail threads between you and another party discussing the relationship between JSR 147 and JSR 170 and potential architectural options. While there has been some interesting discussion on the relationship, I am still quite confused about the architectural use case for one or both of these JSRs. I'm wondering if you can shed any concrete light on use cases for these JSRs together? There seems to be quite an overlap between them with JSR 147 providing a more complete change management spec. and JSR 170 providing other useful functionality like search capability, etc.
I am currently tasked with building a meta-data repository capable of storing both unstructured as well as structured content. I would really like to adopt an implementation of a content repository rather than writing the implementation myself. This would allow me to focus on designing and developing the layer of software on top of, for example the JCR API, that provides context to (or pre-processing of) my structured content. For example, I may have content models that know how to consume Java source files, XML files, and SQL files. I need to develop software on top of the JCR API that bridges my known content to the appropriate JCR node types and API calls.
I'm aware of a few content repository implementations, however, none seem to support either the JSR 147 or JSR 170 specifications. I know there is an Eclipse project called Stellation that is planning on providing a reference implementation for JSR 147. I know the Apache Jakarta Slide project provides a complete content repository implementation today and is planning to provide an implementation for the JSR 147 API as well. We are planning to deploy our solution within the Eclipse environment which makes the Stellation project intriguing. The current Slide implementation is compelling as well as it is usable today. The challenge with Slide would seem to be it is a proprietary API and there doesn't appear to be any mention of support for JSR 170. I feel somewhat compelled to move forward with Slide with an expectation for re-factoring my use of proprietary Slide APIs to appropriate JSR APIs once Slide supports them.
Thanks in advance for your thoughts and response on this post.
Here's an open-source impl for jsr 170: http://www.obinary.com/en/magnolia.html
I haven't used it yet.
Just to set this straight - Magnolia is NOT an open source implementation of JSR-170.
"Magnolia is the free, open source, J2EE deployable content management system (CMS) developed by obinary. Magnolia uses the upcoming standard API for java content repositories (JCR) to access its content. It has an easy to use web-browser interface, a clear API and a useful custom tag library for easy templating in JSP and Servlets. "
It uses the JCR reference implementation from slide.
Thanks for the response Boris.
I'm a bit confused, however, in that I don't see the Slide API providing a reference implementation for the JSR 170 specification. Am i missing something?
The JCR Reference Implementation is found in the jakarta-slide CVS module at proposals/jcrri. A new and improved RI will be checked in shortly so you may want to wait a couple days.
Just to clarify: What this means is that the JCR RI is being hosted by the Slide *project* though the JCR API is not part of, nor in any way synced with the Slide API proper, at least not yet :-)
Thanks Peeter. I'll have a look at this and await changes as they come. This will probably become obvious as I look at the source code, however, it appears as though this effort doesn't leverage stores, etc., directly provided with the Slide product. In other words, it is not an adapter from JCR to the Slide API. As you said (I think) the only commonality between this effort and the Slide product is that they're both hosted within the same Slide project. Perhaps this effort leverages Slide for a WebDAV store. Anyway, can you shed any light on the benefits of pursuing the WVCM proposal over or in addition to the JCRRI proposal? I'm very confused with the overlap between the two initiatives.
Thanks Peeter. I'll have a look at this and await changes as they come.
FYI: the current state of the RI code has been checked back into
the jakarta cvs as a slide.http://www.mail-archive.com/slide-dev at jakarta dot apache dot org/msg10097.html
> This will probably become obvious as I look at the source code, however,
> it appears as though this effort doesn't leverage stores, etc.,
> directly provided with the Slide product. In other words, it is not
> an adapter from JCR to the Slide API. As you said (I think) the
> only commonality between this effort and the Slide product is that
> they're both hosted within the same Slide project. Perhaps this
> effort leverages Slide for a WebDAV store.
that is true at the moment but will hopefully change soon. both
slide and also the jcrri-proposal do have very pluggable "store
abstractions". regarding a possible archicture of integrating
jsr-170 as suggested by remy maucherat maybe this is of interest.http://www.mail-archive.com/slide-dev at jakarta dot apache dot org/msg05538.html
> Anyway, can you shed any light on the benefits of pursuing
> the WVCM proposal over or in addition to the JCRRI proposal?
> I'm very confused with the overlap between the two initiatives.
jsr-147 was (obviously;)) submitted before jsr-170 and had a
a more focussed charter than jsr-170, being closely tied to delta-v.
nevertheless we have a very close collaboration between jsr-147
and jsr-170 in the sense that geoff clemm from ibm, who is the
spec-lead of jsr-147 is also a very active member of the jsr-170
expert group. so we try to have information flowing back and forth
between the expert groups and also benefit from geoff's unique
expertise in the area of versioning.
Thanks David. I'm wondering if there are predicions regarding the future of JSR 147 and 170 living as separate specifications? It seems to somewhat defeat the purpose of having a "standard" content repository API. Would anyone care to prognosticate on the potential for one of these two specifications to go away in favor of a single standard API? If not, what is the rationale behind both JSRs being carried forward? It seems like JSR 147 provides a more complete source code management solution while JSR 170 provides more support than JSR 147 in the area of repository search capability.
Thanks in advance for any responses,
there are a lot of differences between jsr-147 and jsr-170. jsr-170
deals with a fine grained content model and as the title
suggests is a complete content repository api including things like
search, observation, "node-types", etc. while jsr-147 is currently
focused on a more coarse-grained data model and supports
configuration management features like baselines, activities and
as mentioned before currently we are keeping our options open
for the future with geoff clemm being in the jsr-170 expert group.
he makes sure that concepts and ideas flow back and forth between
jsr-170 and jsr-147.
our collaboration has been very fruitful so far therefore i would
not rule out the possibility that we will find ways to combine the
two specifications, dispite their different current foci.
however, currently there are no plans to do so, but we will keep that
Here I'd like to present my first comments. Hope to write a critical (hopefully constructive ;) document soon on the Public Review.
There are many open issues in the document.
I hope that Day is planning to provide two different TCK ("Technology Compatibility Kit") for the two different "Levels". And I hope that the spec leads think thoroghly the interdependences between Level 1 and Level 2. It will be painfull if providers have to go all the way to Level 2 to meet Level 1 ;)
What specifications forget is that, creating a specification is essentially an iterative process. Start small and keep refining as you go. There was an attempt at providing an RI as part of Jakarta Slide but it has been quite a while as the API was yet to stabilize. I think It will be very interesting to see how the reference implementation will look like now.
It will be interesting to see how implementations map a tree data structure on an RDBMS. XML, File system, LDAP should be easier as they are basically tree structures.
Workspace, I feel, should have been left out from the specification. It unnecessarily complicates and polutes the specification.
Day or the document writers should provide a more detailed description of the issues so that the public can do a more constructive reveiew. For instance [Issue #204: Add getName] on page# 55 doesn't tell me anything!
Time will tell whether this attempt leads to easing our(developers) troubles and collective upliftment or ends up just as an attempt at getting marketing/PR mileage by Day.