[Cps4] cps/jcr document mapping

[Florent Guillaume]

On 10 Apr 2006, at 03:13, Tiry wrote:
> Sorry to catch up so ,late.
>
> Some questions ...
>
> Sections / Workspaces :
> ----------------------------------------
>
> There is no way on JCR API to create new JCR Workspace and no way  
> (even
> in the Rabbit) to delete a Workspace.
> So I guess we should avoid having to modify the workspace structure  
> when
> modifying CPS.
>
> So this means there is just a JCR Workspaces for the tree that can
> contains proxy and another one for the tree that can not.
>
> This means that if a project needs to create another CPS Tree (in
> addition to workspaces and sections) it will be created as a new sub
> tree of the Section or Workspace JSR workspace ?

Yes.


> Schema and Fields :
> ----------------------------------
>
> As far as I undestand there is no much left about schemas and  
> fields at
> the CPS level.
> Everything is defined as NodeTyeDef at JCR level.

For the low level yes. It doesn't mean the high level CPS can't  
continue to work with the same concepts, provided they can match (ie  
flat schemas).

> The future equivalment of schema tool is only a (cached) view on  
> the jcr
> NodeTypeDef ?

Yes, with maybe some tools to convert them to readable formats or XSD  
or whatever.

There's a layer we'll still need tough (maybe simplified): ACLs and  
expressions on the fields. XSD and friends don't have that.
However I'd like to simplify that as well (at the moment ACLs and  
expressions on fields are quite costly).

I'll be writing a detailed document with all the changes in the CPS  
basic framework I see coming.

> This will have a big impact on the way we design schemas.
>
> I agree that the best way is propably to align on XSD.
> This could be a good format to store (cache) the schema at CPS  
> level and
> use it for validation. This is also a good design format.
>
> From my point of view, this also means that some of the logic of
> CPSDocument model should perhaps be implemented in the Rabbit  
> connector.
> => more efficient by avoiding to much network exchanges
> => I guess apogee will need to write it in Java anyway

I want to check the performance of a simple model first. And optimize  
later with CPS-specific knowledge of how documents are structured, if  
necessary.

> Transaction stupid question :
> --------------------------------------------------
> Are transaction available across multiples JCR Repositories ?
> I guess yes, but ...

Transaction are available accross all the systems that subscribe to  
the XA "protocol". So, yes.
But we don't plan on using more than one repository for now.

> Last stupid question :
> -------------------------------------
> What is the difference between a contentfragment ( cf mail eb) and a
> dictionary attribute as they are both stored as a sub node with a
> specific nt ?

 From the JCR point of view, there is no difference. It's all in the  
way CPS will interpret it and display it.
Well, actually there is a difference in JCR in how the nodetypes   
specify constraints on their subnodes. For dictionaries, properties  
with arbitrary names will be allowed, and the properties' type will  
be constrained (to a string list for instance). For a content  
fragment, we'd have a general schema with a fixed set of properties  
with a type for each.

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com