You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Walter <wa...@builditglobal.com> on 2005/07/06 16:47:02 UTC
Workspaces and XPath 2.0
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. 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?
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.
Walter Breidenstein
Re: Workspaces and XPath 2.0
Posted by Walter <wa...@builditglobal.com>.
Hi Jukka,
Yes, the concept behind our CMS is to allow each of our customers to
create a project. The project has its own identity within the CMS, but
we would like each project owner to develop also their own web site for
marketing the project (either within the community or to the outside).
It seems that a separate, multiple workspace design is going to be very
effective.
Thanks for the suggestion. Yes, I noticed that my developers have sent
through a couple questions and I forwarded them your comments as well.
Thanks.
Walt.
Jukka Zitting wrote:
> Hi,
>
> Walter Breidenstein wrote:
>
>> Can anyone help me to understand the idea behind workspaces and the
>> reason to have more than one workspace?
>
>
> Workspaces are used to divide a content repository into one or more
> independent sections. For example, a CMS that supports hosting for a
> number of customers might allocate a separate workspace for each
> customer. Or a CMS that supports staging-live setups might reserve one
> workspace as the authoring area and another as the publicly visible
> version of the managed content.
>
> If your content repository supports such concepts, then you'd probably
> do well to include them in your JCR implementation. Otherwise it is
> relatively straightforward to implement a dummy default workspace that
> contains all the content in your content repository.
>
>> "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"."
>
>
> JSR-170 requires a relatively compact XPath subset as detailed in
> section 6.6.4 of the JCR specification. Not knowing the extent of your
> existing implementation, I can't tell how much more work would be
> required to pass the Level 1 requirements.
>
> PS. I'd like to encourage your developers to direct any questions or
> problems they have to this list. I'm sure that there are many people
> (me included) taking on the same issues, and it would only benefit us
> all to share the answers and best practices that surface.
>
> BR,
>
> Jukka Zitting
>
Re: Workspaces and XPath 2.0
Posted by Jukka Zitting <jz...@yukatan.fi>.
Hi,
Walter Breidenstein wrote:
> Can anyone help me to understand the idea behind workspaces and the
> reason to have more than one workspace?
Workspaces are used to divide a content repository into one or more
independent sections. For example, a CMS that supports hosting for a
number of customers might allocate a separate workspace for each
customer. Or a CMS that supports staging-live setups might reserve one
workspace as the authoring area and another as the publicly visible
version of the managed content.
If your content repository supports such concepts, then you'd probably
do well to include them in your JCR implementation. Otherwise it is
relatively straightforward to implement a dummy default workspace that
contains all the content in your content repository.
> "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"."
JSR-170 requires a relatively compact XPath subset as detailed in
section 6.6.4 of the JCR specification. Not knowing the extent of your
existing implementation, I can't tell how much more work would be
required to pass the Level 1 requirements.
PS. I'd like to encourage your developers to direct any questions or
problems they have to this list. I'm sure that there are many people (me
included) taking on the same issues, and it would only benefit us all to
share the answers and best practices that surface.
BR,
Jukka Zitting
Re: Workspaces and XPath 2.0
Posted by Walter <wa...@builditglobal.com>.
David,
Thanks for the example. I am going to instruct my developers to please
set up several workspaces for our implementation as it appears they are
going to be useful for our CMS strategy. I know understand after you
posted this:
"The concept of workspaces stems from "configuration management" as
speced in WebDAV DeltaV and JSR-147."
Yes, I also think this is very helpful when you wrote:
"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 docs/jsr-170-tck-appeal.pdf"
Actually, the repository has been built from scratch. We tried to work with Slide and Tapestry and it did not work the best. Now, it has all been built to the JSR-170 specs, but more yet to complete.
Thank you for your reply. We hope to be certified one day.
Walt.
David Nuescheler wrote:
>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
>scratch.
>
>
>
>>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
>docs/jsr-170-tck-appeal.pdf
>
>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.
>
>regards,
>david
>----------------------------------------------------------------------
>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.
>
>
>mailto:david.nuescheler@day.com
>http://www.day.com
>
>David Nuescheler
>Chief Technology Officer
>Day Software AG
>Barfuesserplatz 6 / Postfach
>4001 Basel
>Switzerland
>
>T 41 61 226 98 98
>F 41 61 226 98 97
>
>
>
Re: Workspaces and XPath 2.0
Posted by David Nuescheler <da...@gmail.com>.
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
scratch.
> 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
docs/jsr-170-tck-appeal.pdf
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.
regards,
david
----------------------------------------------------------------------
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.
mailto:david.nuescheler@day.com
http://www.day.com
David Nuescheler
Chief Technology Officer
Day Software AG
Barfuesserplatz 6 / Postfach
4001 Basel
Switzerland
T 41 61 226 98 98
F 41 61 226 98 97