jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Walter <walt...@builditglobal.com>
Subject Re: Workspaces and XPath 2.0
Date Thu, 07 Jul 2005 11:02:18 GMT
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
>
>  
>

Mime
View raw message