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 implementationrather 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 manyfunctional 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 packagedocs/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! ---------------------------------------< [EMAIL PROTECTED] >--- 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:[EMAIL PROTECTED] 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
smime.p7s
Description: S/MIME Cryptographic Signature
