Hi Chand, Thanks for your email and thanks for the link to jlibrary.
First of all I would like to express my appreciation for all the work done and I think it is fantastic to see applications like jlibrary operate on JCR. This is precisely what JCR is meant to be used for. I think jlibrary also demonstrates in an impressive way the need for some guidelines around "Content Modeling" in general and "Nodetype Modelling" in particular. So jlibrary may be a very good example to explain the caveats, pro and cons, dos and don'ts around nodetype modelling. What do you think would be a good forum for an initial set comments and dialog around the jlibrary content model? Since Martin is also active on jackrabbit-dev list, this may well be a good place to start the discussions from which we then can harvest the best practices around "content modelling". With respect JSR-283, I would like to answer as a member of the expert group (neither as the spec-lead nor on behalf of the expert group). In my mind JCR should still try to stay out of semantic information modelling as much as possible. Having said that, there are a few select areas where the benefit of interoperability by "imposing" a given very well-known and established data model outweigh the associated dangers and efforts. Examples from JSR-170 are nt:file, nt:folder and nt:resource. In JSR-283 I personally would expect few and very simple nodetypes that describe very well-known, established and frequently used concepts. Personally, I think of things like a dublin-core or a "natural language" mixin. Of course I am big believer in having a large number of publicly known and well organized nodetypes, and any form of complex media-types are perfect examples. For an effort like that I would suggest a different platform than the JCP that offers faster modification cycles and a more open, less formalized and more collaborative environment. Maybe the Jackrabbit project could host something like a "Public Nodetype Library" initially? [ http://zitting.name/jukka/2004/11/jackrabbit/msg00134.html ] regards, david On 2/20/06, Chandresh Turakhia <[EMAIL PROTECTED]> wrote: > Dear David , > > Jlibrary has done some nice work modelling nodes which basic applications > need. > > http://jlibrary.sourceforge.net/6/hierarchy.html .JLibrary is Open Source DMS > using Eclipse RCP by Martin. > > Even exo has done some decent work - Creating standard services like > templating based on JSF+Velocity which most CMS need * use internally.Nice to > have something that goes as standard sample repositories. So that it > facilitates easy integration of various CMS. > > JSR 283 Extract : > > - Improvement of content repository interoperability through the addition of > new standardized node types , including node types for meta information and > internationalization > > Idea is to have standard nodes for DRM , MPEG 7 DDLs, MPEG 21 files. > > Standard property1 : AdaptableRenderer > > property2 : AdaptablePersister > > property3 : AdaptableQuery > > > WORK DONE ON OUR SIDE : Most of these come as XSD files. Create Node for each > and store using XMLBeans or Hibernate 3 . Hibernate3 is ORXM tool. It is XML > mapping tool too. > > > Mr Leonardo from Chiarglione seems to be doing some great work in this area. > (http://www.dmpf.org/). > > Idea is when standard node is getting processed, rendering engine ( may be > OpenLazzlo) checks for the property and uses it to create appropriate > display. IDEA inspired by WSRP. Data stored info as to how to render itself > in Portal frameworks. > > And use Persister property to get best of RDBMS (e.g Oracle Intermedia > features ). Depending upon the content type ( Custom Node ) , different > persistance mechanism can be usitilized.Joseph from Oracle could be of good > help.Exo Uses Hibernate and it can be this task easy. :) > > EXO uses hibernate , so I think it should be easy to do. Benjabin should be > able to guide. > > Of the track, but Something really interesting from Dr. Peiya Liu of Siemens > Research to read > > http://www.idealliance.org/papers/xmle02/dx_xmle02/papers/03-02-01/03-02-01.html > e.g. MMDOC-QL for specifying MPEG-7 XML document queries. An example of > query is in the form of "finding all video object ids and show up time over a > particular area". > > Basically somehow the idea goes against the principle of JSR 170 as I > understand to NORMALIZE the datastructure, to use the best features. > > Architecturally , When the XQuery based application finds the document of > certain type, application uses SubClassed Renderer,Query Engine. > > Regards > > Chand Turakhia > > > > -----Original Message----- > > From: David Nuescheler [mailto:[EMAIL PROTECTED] > > Sent: Sunday, February 19, 2006 10:11 AM > > To: jackrabbit-dev@incubator.apache.org; > > [EMAIL PROTECTED] > > Subject: Re: Copy of JSR 283. > > > > hi chand, > > > (Q1) Where can I get copy of JSR 283 ? > > jsr-283 is work in progress and there is no public copy available yet. > > anyway jackrabbit is based on jcr v1.0 as specified by jsr-170, which > > can be downloaded from the jcp site. > > > (Q2) Is there any best practice tutorial to "model" > > > application data/content using JCR. > > there are only public examples rather than actual best practices. > > personally i would greatly appreciate some effort in this direction > > maybe as part of the jackrabbit documentation. > > regards, > > david > > > > -- ---------------------------------------------------------------------- http://jcr.day.com JCR 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
