jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject Re: Workspaces and XPath 2.0
Date Wed, 06 Jul 2005 15:54:45 GMT
Hi Walter,

Thanks for your inquiry.

> I am a CEO of a company that has hired developers to make our CMS
> JSR-170 compliant and they have been working on this implementation
> rather successfully.  
Congratulations. As a matter of fact I would argue that you probably
are looking into making your repository jsr-170 compliant not your CMS.
I think it is a great decision to make your repository compliant since 
JSR-170 can help you protect your technology investments for 
yourself and your customers.
As a provider of a Content Repository "Application" (CMS) 
JSR-170 introduces even more interesting options for. 
You may in the future build your CMS based on a standard 
based "third party" content repository such as Jackrabbit 
instead of developing the content repository commodity from 

> However, I was informed today that in order to be
> certified compliant by Day, we will need to implement workspaces.
> According to the Spec, it reads:
> "A content repository is composed of a number of workspaces. Each
> workspace contains a single rooted tree of items. In the simplest case a
> repository will consist of just one workspace. In more complex cases a
> repository will consist of more than one workspace."
> Can anyone help me to understand the idea behind workspaces and the
> reason to have more than one workspace?
First of all the specification does not force you to have more
than one workspace. Only the advanced versioning operations
use multiple workspaces. Your question centered around why
someone would have more than one workspace, makes me think
that advanced versioning and configuration management is not
a focus in your current repository implementation.

There are many use cases for multiple workspaces. 

One of the use cases that you may typically find in CMS is 
that you have a v2.0 of let's say a "public website" in preparation, 
where you may want to leverage a lot of the existing content but 
let's say "re-arrange it".

Since the process of launching your new website takes
weeks or months you may want to keep track of all the
small fixes that people make on the v1.x website (typos, ...).

So you could have your 2.0 workspace with a completely
reworked navigation and a large amount of content changes
and merge/update from your 1.x workspace to stay in sync.

The concept of workspaces stems from 
"configuration management" as speced in 
WebDAV DeltaV and JSR-147.

This is just one of many very different use cases.
Does that make sense to you? 

> Also, they have this problem to be compliant:
> "However there is one serious thing which requires more carefull
> considerartion: *XPath query* specified by level 1. Initially we added
> only basic support for the simple XPath queries. The TCK uses more
> advanced XPath and so tests are failing. JSR-170 uses XPath 2.0
> <http://www.w3.org/TR/xpath20/> which is still in "working draft"."
> Again, please know that I am not a developer, but it is my obligation as
> CEO to fund the continuation of the development work to deal with these
> additional issues.  Any assistance from anyone who can speak in simple
> english would be very much appreciated.
The specification mandates a relatively simple set of features with relation
to Query. In the specification those features are wrapped into an XPath and
SQL syntax expressing the same feature set.

With respect to parsing the XPath query I would suggest that your 
developers may want to have a look at the source code of Jackrabbit
and use portions of it for their implementation. 
Jackrabbit is licensed under the Apache license it allows for 
commercial use of any portion of the source code. 

Generally speaking, as a developer I would most certainly use as
much as possible from the code base of Jackrabbit, since many
functional blocks are already solved, tested and compliant by the 
TCK. As a matter of fact I would probably not even start building
my own repository anymore, but use existing commercial or 
open source implementations. Building your own repository may
soon be compared to building your own RDBMS or J2EE 
Application Server.

In case your developers think that a test case in the TCK 
goes beyond what the specification mandates they can 
challenge that particular test case, following the 
"First Level Appeal Process" in the TCK package

I hope this may have clarified some of your questions.
If not, feel free to either contact me directly or post more
questions to this list.

http://jcr.day.com JSR-170 in Action!
---------------------------------------< david.nuescheler@day.com >---

This message is a private communication. If you are not the intended
recipient, please do not read, copy, or use it, and do not disclose it
to others. Please notify the sender of the delivery error by replying
to this message, and then delete it from your system. Thank you.

The sender does not assume any liability for timely, trouble free,
complete, virus free, secure, error free or uninterrupted arrival of
this e-mail. For verification please request a hard copy version.


David Nuescheler
Chief Technology Officer
Day Software AG
Barfuesserplatz 6 / Postfach
4001 Basel

T  41 61 226 98 98
F  41 61 226 98 97

View raw message